Implementing Secure Network Access Authentication
Although
it’s outside the scope of this chapter to go into the details of PKI,
it is useful to look at some of the ways PKI can be used as part of a
Windows-based authentication infrastructure for secure network access
using the protocols discussed in this section.
When
using PEAP–MS-CHAPv2 for network access authentication, configure Group
Policy for autoenrollment of computer certificates to install computer
certificates on the NPS servers.
When
using certificates for computer-level network access authentication,
you should configure Group Policy for autoenrollment of computer
certificates. This applies if you’re using EAP–TLS or PEAP–TLS for
computer-level wireless authentication.
When
using certificates for user-level network access authentication,
configure a certificate template for user certificates and also
configure Group Policy for autoenrollment of user certificates. As with
computer-level certificates, this is needed when using EAP–TLS and
PEAP–TLS.
Group
Policy is also an important part of securing network access and
authenticating computers and users. You can use Group Policy to deploy
settings to install a root certificate on a domain member computer to
validate computer certificates of the NPS servers. It can also be used
to autoenroll user and computer certificates on domain member computers
for user- and computer-level certificate-based authentication.
In
addition to being useful in the deployment of certificate-based
authentication, Group Policy is also useful in deploying configuration
settings for:
802.11 wireless network profiles
802.1x wired network profiles
Windows Firewall with Advanced Security connection security rules to protect traffic
NAP client configuration
|
PPP-based
connections no longer support the SPAP, EAP-MD5-CHAP and MS-CHAPv1
authentication protocols. Remote access PPP-based connections now
support the use of Protected EAP (PEAP) with PEAP-MS-CHAP v2 and
PEAP-TLS. Keep this in mind as you plan out your new Windows Server
2008 remote access options.
EAPHost
architecture in Windows Server 2008 and Windows Vista includes new
features not supported in Windows Server 2003 and Windows XP including:
Support for additional EAP methods Network discovery (as defined in RFC 4284) RFC 3748 compliance and support for expanded EAP types including vendor-specific EAP types Coexistence of multiple EAP types (Microsoft and Cisco, for example)
|
|
You can configure wired policies form the Computer Configuration | Policies | Windows Settings | Security Settings | Wired Network (IEEE 802.3) Policies node in the Group Policy Management Editor snap-in via the MMC. By default, there are no wired policies in place. To create a new policy, use the following steps:
1. | Right-click the Wired Network (IEEE 802.3) Policies in the console tree of the GP Editor snap-in.
| 2. | Click Create A New Windows Vista Wired Policy.
| 3. | The New Windows Vista Wired Policy Properties dialog is displayed, shown in Figure 3. It has two tabs: General and Security. The General
tab is selected by default. Enter the policy name and description and
ensure the checkbox for “Use Windows Wired Auto Config service for
clients” is checked.
| 4. | Click the Security
tab to set security options. On this tab, click the checkbox next to
“Enable use for IEEE 802.1X authentication for network access” then
click the dropdown box to select a network authentication method (EAP,
PEAP, MS-CHAPv2). Also select the “Authentication Mode” from the second
dropdown box. The options are User re-authentication, computer only,
user authentication, or guest authentication. Also select the number of
times the authentication can fail before it is abandoned (1 is the
default). The last setting in the Security tab is a checkbox whether to
“Cache user information for subsequent connections to this network.” If
this checkbox is cleared, the credential data is removed when the user
logs off. If the checkbox is checked, the credential data will be
cached after user log off.
| 5. | To access advanced settings, click the Advanced button on the Security tab. There are two Advanced segments: IEEE 802.1X and Single Sign On, shown in Figure 4.
| 6. | In the IEEE 802.1X
section, click the checkbox to the left of “Enforce advanced 802.1X
settings” to enable these options: Max Eapol-Start Msgs:, Held Period
(seconds), Start Period (seconds), Auth Period (seconds), Eapol-Start
Message. In most cases, the default settings are fine; it you believe
you need these advanced settings, check the Microsoft documentation for
details on how to set these.
| 7. | In the Single Sign On
section, click the checkbox next to “Enable Single Sign On for this
network” to enable the following options: Perform immediately before
User Logon, Perform immediately after User Logon, Set Max. delay for
connectivity (seconds), Allow additional dialogs to be displayed during
Single Sign On, and This network uses different VLAN for authentication
with machine and user credentials. Again, as with the IEEE 802.1X
Advanced settings, these can be modified if you have a specific need to
do so. Check Microsoft documentation for details on using these options
within your network environment. A good starting place is www.microsoft.com/technet/technetmag/issues/2008/02/CableGuy/default.aspx.
| 8. | Click OK to accept configuration; click Cancel to exit without saving changes.
|
|
Routing and Remote Access Services (RRAS) Authentication
Routing
and Remote Access Services (RRAS), installed via the NPS, enables users
to be authenticated and to connect to the network remotely. RRAS
services are similar to those in Windows Server 2003, though there are
a few updates to be aware of. For details of the Windows Server 2008
changes, read the New & Noteworthy section that precedes this
section.
As we’ve
mentioned, EAP-TLS and PEAP-TLS are supported in Windows Server 2008
and the less secure PEAP-MS-CHAPv2 is supported when certificates are
not available. RRAS policies are configured here as well as via Group
Policy in AD.
We’re
assuming you already have an understanding of a security infrastructure
(AD, PKI, etc.), so we’ll build on that knowledge. As you know, RRAS
can be configured via Group Policy so you can control access based on
group membership—whether that’s a computer or user group. The most
popular method of remote connection these days is through a Virtual
Private Network (VPN) connection. You can secure that connection of a
remote computer and the local network in different ways. The three
methods in Windows Server 2008 are:
Point-to-Point Tunneling Protocol (PPTP)
Layer Two Tunneling Protocol with Internet Protocol security (L2TP/IPsec)
Secure Socket Tunneling Protocol (SSTP)
Point-to-Point
Tunneling Protocol (PPTP) uses PPP authentication methods for
user-level authentication and it uses Microsoft Point-to-Point
Encryption (MPPE) for
data encryption. Layer Two Tunneling Protocol with Internet Protocol
security (L2TP/IPsec), like PPTP, uses PPP for user-level
authentication but it uses IPsec for computer-level security that
includes peer authentication, data authentication, data integrity, and
data encryption. Secure Socket Tunneling Protocol (SSTP) also uses PPP
for user-level authentication and it uses Hypertext Transfer Protocol
(HTTP) encapsulation over a Secure Sockets Layer (SSL) channel
(Transport Layer Security) for data authentication, data integrity, and
data encryption.
A
remote client makes a remote connection via VPN to a private network
through a VPN server, which provides access to the network to which
that VPN server is connected. During the connection process, the VPN
client authenticates itself to the VPN server. Depending on how VPN
connections are configured, the VPN server may also authenticate itself
to the client.
Warning:
This section refers to modifying the Windows registry file. Using
Registry Editor incorrectly can cause serious problems that may make
the system unstable or unusable and that may require you to reinstall
the Windows operating system. There is no guarantee that problems
resulting from the incorrect modification of the Registry file can be
solved. Edit or modify the Registry at your own risk and do not do this
on a live server unless you know exactly what you’re doing and have a
backup of the Registry. Always make a backup of the Windows Registry
file before you modify any settings. You can back up the entire
Registry or a single portion of the Registry using REGEDIT. For more
information on backing up and restoring the Registry file, visit http://support.microsoft.com/kb/136393.
By
default, Windows Server 2008 and Windows Vista have MPPE encryption
with 40-bit and 56-bit keys disabled. Instead, the stronger 128-bit
encryption is enabled. You can configure Windows Server 2008 to use
40-bit and 56-bit keys if you have a need to connect with Windows
Server 2003 or Windows XP SP2-based computers. This can be enabled by
setting the HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\Rasman\parameters\AllowPPTPWeakCryptoregistry
value to 1 and restarting the computer. Keep in mind, however, that
this is a weaker encryption system and generally is not recommended.
As
mentioned previously, support for the Message Digest (MD5) hash has
been discontinued in L2TP/IPsec. Now, Windows Server 2008 supports only
3DES encryption and the Secure Hash Algorithm-1 (SHA1) hashed method
authentication code (HMAC) by default. Support for the Advanced
Encryption Standard (AES) using 128-bit or 256-bit keys has been added.
As with MPPE encryption, you can enable MD5 support for
interoperability, but this also is not recommended. If you have reason
to enable this, you can access it via the following registry key and
setting the value to 1: HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\Rasman\parameters\AllowL2TPWeakCrypto.
Any
time you modify a registry key, you need to restart the computer before
the setting takes place. Again, these changes are not recommended as
they weaken security, but they can be modified if needed.
